Encryption and decryption of data  owned by a guest operating system

ABSTRACT

An apparatus includes one or more processor core, trusted key store, memory controller, and a memory module. The memory controller includes an encryption/decryption module that encrypts data being stored to the memory module for a guest OS being executed by the processor core(s) and that decrypts data being read from the memory module for the guest OS. Data owned by the guest OS is encrypted and decrypted by the encryption/decryption module using an encryption key stored by the trusted key store in association with the guest OS. A method encrypts data owned by the guest OS using the encryption key assigned to the guest OS and stores the encrypted data on a memory module, wherein the encrypted data is stored in association with the process identifier of the guest OS, and decrypts the encrypted data using the guest OS encryption key and provides the decrypted data to the guest OS.

BACKGROUND

The present disclosure relates to systems and methods of maintainingsecurity of guest operating system data from a host operating system ina multi-tenant cloud environment.

BACKGROUND OF THE RELATED ART

In a hosted workload environment, where multiple workloads may share thesame processor simultaneously, all workloads have to grant trust to thehost. This is due to the fact that the host operating system and othersimilar software (such as debuggers and other hardware analysis tools)can inspect all detailed processor state data. However, in amulti-tenant environment, such as a public cloudinfrastructure-as-a-service (IaaS) implementation, there is a potentiallack of security or trust problem in that the host operating system maybe able to read data belonging to a guest operating system.

BRIEF SUMMARY

One embodiment provides an apparatus comprising one or more processorcores, a trusted key store operatively coupled to the one or moreprocessor cores, a memory controller operatively coupled to the one ormore processor cores and the trusted key store, and a memory moduleoperatively coupled to the memory controller. Furthermore, the memorycontroller includes an encryption and decryption module that encryptsdata being stored to the memory module for a guest operating systembeing executed by the one or more processor cores and that decrypts databeing read from the memory module for the guest operating system,wherein data and instructions owned by the guest operating system areencrypted and decrypted by the encryption and decryption module using anencryption key stored by the trusted key store in association with theguest operating system.

Another embodiment provides a method comprising executing a hostoperating system and a guest operating system on one or more processorcores, and storing a process identifier assigned to the guest operatingsystem in association with an encryption key received from the guestoperating system in a trusted key store, wherein the encryption keyreceived from the guest operating system is not accessible to the hostoperating system. The method further comprises encrypting data owned bythe guest operating system using the encryption key received from theguest operating system and storing the encrypted data on a memory modulein response to a write command from the guest operating system, whereinthe encrypted data is stored on the memory module in association withthe process identifier of the guest operating system, and decryptingencrypted data owned by the guest operating system using the encryptionkey received from the guest operating system and providing the decrypteddata to the guest operating system in response to a read command fromthe guest operating system.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

FIG. 1 is a diagram of an apparatus including a CPU package that has atrusted key store according to one embodiment.

FIG. 2 is diagram of an apparatus including a CPU package according toanother embodiment.

FIG. 3 is a flowchart of a method according to one embodiment.

FIG. 4 is a flowchart of a method according to another embodiment.

DETAILED DESCRIPTION

One embodiment provides an apparatus comprising one or more processorcores, a trusted key store operatively coupled to the one or moreprocessor cores, a memory controller operatively coupled to the one ormore processor cores and the trusted key store, and a memory moduleoperatively coupled to the memory controller. Furthermore, the memorycontroller includes an encryption and decryption module that encryptsdata being stored to the memory module for a guest operating systembeing executed by the one or more processor cores and that decrypts databeing read from the memory module for the guest operating system,wherein data and instructions owned by the guest operating system areencrypted and decrypted by the encryption and decryption module using anencryption key stored by the trusted key store in association with theguest operating system.

The trusted key store may take the form of a trusted platform module(TPM), which is a dedicated microcontroller. Accordingly, the trustedplatform module may interface with one or more encryption and decryptionmodules to provide the encryption key associated with the guestoperating system. Preferably, the guest operating system will beassigned a process identifier and the encryption key will be stored inassociation with that process identifier. Optionally, the trustedplatform module and the one or more processor cores may be located onthe same chip.

The encryption key may be assigned to the guest operating system by theencryption and decryption module or by the trusted key store uponinitial execution of the guest operating system in the one or moreprocessor cores. Regardless of which entity generates or assigns theencryption key, the encryption key is stored in the trusted key store inassociation with a process identifier, such as a tag. In order toestablish a private execution domain between the guest and the CPUitself, a secure trust domain may be constructed before this tagassignment can be made.

In a preferred embodiment, the guest operating system is delivered tothe host processor in an encrypted form and the guest exchanges a keywith the host processor via any preferred method for secret exchangeusing cryptography, so long as the key exchange maintains protectionagainst so-called “man-in-the-middle” attacks. For example, unencryptedinitialization code that initializes the key exchange can be deliveredfrom the guest to the host such that the initialization code can beexecuted on the host processor to perform an exchange of public keysbetween the guest and the host. The execution of this initializationcode can be measured by a host device, such as a TPM, to establish thatthe initialization code has not been altered by another piece of hostsoftware that has access to the processor and instruction memory. Inthis initialization process, the host processor presents a digitalcertificate that has been signed by a certificate authority that hasestablished trust to all involved parties. This digital certificateincludes the host's public key for encryption of messages to the one ormore processor cores. The guest then presents its own public encryptionkey to the host so that the guest and host may then perform a secureexchange, for example using an algorithm such as Diffie-Hellman. Oncethe one or more processor cores have assigned a process tag to the guestand has shared the guest's process tag with the guest via this securechannel, the guest can supply the one or more processor cores with asymmetric encryption key for the encrypted portion of the workload andsecure processing can commence. The guest's symmetric encryption key isthen stored in the trusted key store in association with the process tagassigned to the guest, such that the host processor can subsequentlyencrypt and decrypt data and instructions on behalf of the guest.

In secure processing according to the present embodiment, when data isbeing written to the memory module on behalf of the guest operatingsystem, the encryption and decryption module may receive a write commandand the process identifier for the guest operating system, provide theprocess identifier to the trusted key store in a request for theencryption key associated with the process identifier, then use theencryption key provided by the trusted key store to encrypt the dataprior to storage of the encrypted data and the process identifier on thememory module.

The apparatus may further include cache memory in the communication pathbetween the memory controller and the memory module, wherein all datastored on the cache memory is encrypted using the encryption keyassociated with the guest operating system that owns the data.Accordingly, the data received by the cache memory is already encrypted,such that data exchanged between the cache memory and the memory moduleremains encrypted in either direction. The encryption and decryptionmodule is responsible for encrypting data that is being stored in eitherthe cache memory or the memory module and for decrypting data that isbeing provided to the processor from either the cache memory or thememory module. In this manner, the data owned by the guest operatingsystem is secured by encryption wherever the data is stored beyond theone or more processor cores. The cache may be any one or more cache ofany type or level, such as a level three cache.

In another embodiment of the apparatus, the one or more processor coresmay include data registers and an encryption and decryption module thatencrypts data being stored to the data registers for a guest operatingsystem being executed by the one or more processor cores and thatdecrypts data being read from the data registers for the guest operatingsystem. The data stored on the data registers that is owned by the guestoperating system may be encrypted and decrypted by the encryption anddecryption module of the one or more processor cores using theencryption key stored by the trusted key store in association with theprocess tag assigned to the guest operating system. Accordingly, eventhe data stored in a data register within the one or more processorcores may be secured by encryption, such that a host operating system orother process being executed by the one or more processor cores will notbe able to successfully read the data.

Another embodiment provides a method comprising executing a hostoperating system and a guest operating system on one or more processorcores of a central processing unit package, and storing a processidentifier assigned to the guest operating system in association with anencryption key received from the guest operating system in a trusted keystore, wherein the encryption key received from the guest operatingsystem is not accessible to the host operating system. The methodfurther comprises encrypting data owned by the guest operating systemusing the encryption key received from the guest operating system andstoring the encrypted data on a memory module in response to a writecommand from the guest operating system, wherein the encrypted data isstored on the memory module in association with the process identifierof the guest operating system, and decrypting encrypted data owned bythe guest operating system using the encryption key received from theguest operating system and providing the decrypted data to the guestoperating system in response to a read command from the guest operatingsystem.

The method may further include verifying that the read command is fromthe guest operating system (or other guest process). For example,verifying that the read command is from the guest operating system mayinclude determining that the read command includes a process identifierthat matches the process identifier stored on the memory module inassociation with the encrypted data and that the read command comes froman instruction stream (or “workload”) authenticated as belonging to theguest operating system via the successful decryption of that guestoperating system instruction stream using its previously-sharedencryption key. Accordingly, if a read command is received from aprocess having a process identifier that does not match the processidentifier stored in the memory module along with the requested portionof the encrypted data, or if the instructions packaged with theidentifier are not encrypted with the encryption key for the workloadassociated with the identifier, then the encryption and decryptionmodule may not decrypt the requested portion of the encrypted data. Onlya process, such as the guest operating system, that owns data stored onthe memory module will be able to have that data decrypted. As describedherein, ownership of data is shown by having a process identifier thatmatches the process identifier stored in association with the encrypteddata and having instructions that have a trusted chain of provenancefrom the owning (guest) process. For example, the trusted chain ofprovenance (or history of ownership by a process) may be provided byembodiments herein that do not allow for tampering with the instructionsstream associated with the given process identifier and its encryptionkeys within the processor.

Optionally, the process identifier may be a plurality of tag bits. In apreferred embodiment, the host CPU package associates the tag bits thatidentify a guest operating system with all processor instructions of theguest operating system, the encryption key(s) of the guest operatingsystem, and all data owned by the guest operating system. In a furtheroption, data owned by the guest operating system includes data owned byany application being run on the guest operating system, such that theguest operating system and applications being run by the guest operatingsystem may share data that is not accessible to the host operatingsystem.

The method may further include steps to secure data stored within thecentral processing package, such as data stored in a data register. Forexample, the method may further include encrypting data owned by theguest operating system using the encryption key associated with theguest operating system and storing the encrypted data on a data registerof the central processing unit package, wherein the encrypted data isstored on the data register in association with the process identifierassigned to the guest operating system. The method may also includedecrypting encrypted data stored on the data register and owned by theguest operating system using the encryption key associated with theguest operating system and providing the decrypted data to the guestoperating system.

Embodiments disclosed herein enable a guest operating system to secureits data in storage, in memory, and/or in transit to and from theprocessor. The processor may have a mode for running guest operatingsystem code that decrypts memory content inbound to the processor, andencrypts outbound content. The guest operating system mode also preventsthe host operating system from reading the virtualized CPU state of theguest operating system as it is being executed on the host CPU package.

The processor may have its own secure channel to a trusted platformmodule (TPM), which may be integrated inside the processor. When a guestoperating system is launched, the processor enters guest operatingsystem mode and retrieves from the TPM the encryption/decryption keyassociated with the launched guest. Guest operating system mode may alsobe implemented per-core, with a processor core or groups of processorcores assigned to different security domains for each guest operatingsystem. Any processor core running the host operating system orhypervisor would not have access to the encryption key for the guestoperating system, and thus would not be able to see inside the memory orCPU state of the guest operating system being executed on the host CPUpackage.

One embodiment provides a CPU package comprising a first processor coreforming an instruction path, a data register that is externallyaccessible through a debug port, a first encryption and decryptionmodule disposed in a communication path between the instruction path andthe data register, and a key store accessible to the first encryptionand decryption module. The first encryption and decryption moduleencrypts and stores data in the data register for each of a plurality ofprocesses being handled in the instruction path, wherein data owned byeach process is encrypted and decrypted by the first encryption anddecryption module using an encryption key associated with the process.Furthermore, the key store will store the encryption key associated witheach of a plurality of processes, wherein the key store is inaccessibleoutside the CPU package.

Optionally, the first encryption and decryption module may also receiveand store an encryption key for each of the plurality of processes beinghandled in the instruction path. In a separate option, the data registeror other data structure may store the encrypted data along with aprocess identifier or tag assigned to the process that owns the data.Still further, each process identifier may be assigned to a guestprocess by a host operating system that is running on the CPU package.

In a further embodiment, the CPU package may further comprise a memorycontroller including cache memory, and a second encryption anddecryption module disposed in a communication path between the firstprocessor core and the cache memory. The second encryption anddecryption module may encrypt and store data in the cache memory foreach of a plurality of processes being handled in the instruction path,wherein data owned by each process is encrypted and decrypted by thesecond encryption and decryption module using an encryption keyassociated with the process, wherein the second encryption anddecryption module has access to the key store.

In a still further embodiment, the CPU package may comprise a memorycontroller including cache memory, and a second encryption anddecryption module disposed in a communication path between the firstprocessor core and the cache memory, wherein the second encryption anddecryption module encrypts and stores data in the cache memory for eachof a plurality of processes being handled in the instruction path,wherein data owned by each process is encrypted and decrypted by thesecond encryption and decryption module using an encryption keyassociated with the process. However, the CPU package may furthercomprise a second key store that is accessible to the second encryptionand decryption module and may store the encryption key associated witheach of the plurality of processes, wherein the second key store isinaccessible outside the CPU package. Optionally, the first and secondkey stores may store a different encryption key for each of theplurality of processes. The CPU package may further comprise a secondprocessor core, wherein the first and second processor cores share asingle key store.

Still further, the CPU package may further comprise a plurality ofexternally accessible data structures, and a plurality of encryption anddecryption modules, each encryption and decryption module controllingdata into and out of one of the externally accessible data structures.

Another embodiment provides a method comprising a CPU package executinga plurality of processes, wherein each process is assigned a processidentifier, storing an encryption key for each of the plurality ofprocesses, and storing, for each of the processes, the processidentifier assigned to the process in association with the encryptionkey for the process in a key store that is not accessible outside theCPU package. The method further comprises encrypting, for one or more ofthe processes, processor state data owned by a process using theencryption key associated with the process and storing the encryptedprocessor state data and the process identifier in an externallyaccessible processor data structure, and decrypting a requested portionof the encrypted processor state data stored in the processor datastructure and providing the decrypted processor state data to arequesting process in response to receiving a read request from therequesting process having a process identifier that matches the processidentifier stored in the processor data structure along with therequested processor state data.

In one embodiment, the host operating system may be certified astrustworthy by all participating processes via trusted executionmeasurements, digital signing of the operating system code, andprotection of the operating system structures via privileged executionisolation, such that participating processes cannot compromise theshared operating system resources that establish and maintain the secureexecution environments for participating processes.

The method may further comprise preventing decryption of a requestedportion of the encrypted processor state data stored in the processordata structure in response to receiving a read request from therequesting process having a process identifier that does not match theprocess identifier stored in the processor data structure along with therequested processor state data.

The externally accessible processor data structure may, for example, beselected from the group consisting of a buffer, register, cache memoryand combinations thereof. In one option, all externally accessibleprocessor state data that is stored within the CPU package is encryptedwith an encryption key that is specific to the process that owns thedata. In another option, the externally accessible processor datastructure is accessible to an external debugger application through adebugger port.

In a further embodiment, the method may further comprise a selectedprocess, from among the one or more processes, granting access to dataowned by the selected process to a second process by allowing the secondprocess to use the process identifier of the selected process. Forexample, the second process may be a debugger process or a sharedlibrary. Still further, the step of the selected process granting accessto data owned by the selected process to a second process, may includethe operating system automatically associating the process identifier ofthe selected process with the second process in response to the selectedprocess calling the second process.

In another embodiment, the method may further comprise detecting that anexternal entity located outside of the CPU package is attempting toaccess the externally accessible data structure, and determining whetherthe external entity has a process identifier that matches the processidentifier stored along with the data being accessed. For example, theexternal entity may be a debugger application running on a differentcomputer that is externally connected to the CPU package through a debugheader. The method may optionally include exporting the processidentifier from a process that is to be debugged to the debuggerapplication. This exporting would typically be done via an encryptedexchange such as described previously, perhaps using Diffie-Hellman or asimilar method to prevent man-in-the-middle interception of the processidentifier or so-called replay attacks.

In yet another embodiment, the process identifier may be represented bya plurality of tag bits. Accordingly, the method may include the CPUpackage associating the tag bits of a process with all instructions ofthe process and all data owned by the process. One method may use thetag bits associated with an instruction as an index into the key store,and use the encryption key that is stored in the key store inassociation with the tag bits to decrypt the data in the processor datastructure. Still further, the method may use the tag bits associatedwith an instruction as an index into the key store to retrieve theassociated encryption key from the trusted key store, and use theencryption key that is stored in the key store in association with thetag bits to encrypt data owned by a process that includes theinstruction.

In a further embodiment, the method may further comprise the CPU packagedetermining that a process is a new process in response to handling aprocess with a process identifier that is not found in the key store orother table of active processes. The method may then assign a key-tagpair to the new process, wherein the key-tag pair is unique among otheractive processes, and store the key-tag pair in the key store.Optionally, in systems where the assignment and storage of key-tag pairsis controlled by the trusted operating system code, a key-tag pair maybe reused or reassigned to new process after the key-tag pair is nolonger in use by any other active process.

The disclosed embodiments may prevent unauthorized access to processorstate data on a per-process basis. All data stored within a CPU isassociated with an encryption key that is specific to the process thatgenerated the data. Any movement of data onto or off of an externallyreadable data structure of the CPU will result in an encryption ordecryption action, respectively. Externally readable processor datastructures include, for example, buffers, registers and cache memory.

For example, data stored in registers that can be read by a debuggerprocess is encrypted. If the CPU needs access to the data stored inthose registers, the data must be decrypted. If a debugger processattempts access to the data stored in those registers, the debuggerprocess would obtain either the encrypted data or a redactedrepresentation of the register state (i.e. an indication that theregister is unreadable because of permission deficiency). The tenant orguest process that owns the data may, optionally, grant trust to thedebugger process or other cooperating trusted process, such as a sharedlibrary, on a case by case basis. When the tenant process grants trustto another process, that other process may receive decrypted data ownedby the tenant process. However, a grant of trust from the tenant processonly extends to the data that is owned by the tenant process. In otherwords, a grant of trust from a tenant process (the “grantor”) to anotherprocess (the “grantee”) can convey an access privilege no broader thanthe access privilege of the tenant process.

As data and instructions traverse the CPU pipeline data path within theCPU package, the CPU tracks the identity of the process (i.e., viaprocess ownership tag bits) that owns the data and the instructions. Ifa process has permission to access certain data, then the CPU executeslogic to decrypt the data for the process. A process identifier, such aset of tag bits, associated with a process that is attempting access tothe encrypted data is used as an index into a key store that is presenton the host CPU and not accessible to entities outside the CPU. The keystore maintains a list of active processes and, for each active process,an associated tag (i.e., tag bits) and a unique encryption key.

In order to encrypt data from a process or decrypt data requested by aprocess, the encryption and decryption module uses the processidentifier associated with the process to retrieve the associatedencryption key from the trusted key store. The encryption and decryptionmodule then uses the process-specific encryption key to encrypt databeing stored or decrypt data being read by a process having theassociated process identifier. When storing data to the data storagestructure, the encryption and decryption module encrypts the data usingthe process-specific encryption key and delivers the encrypted data tothe data storage structure for storage. When retrieving data from thedata storage structure, the encryption and decryption module uses theprocess-specific encryption key to decrypt the data being accessed anddelivers the decrypted data to the requesting process, subject to therequesting process having a process identifier that is the same as theprocess identifier of the process that stored the data. In other words,only the process that owns the data or a process that has receivedpermission form the process that owns the data will be able to accessthe data.

In one embodiment, the encryption and decryption module may implement aredacting mechanism, for example in which no data is provided to anexternally readable data structure unless the requesting process orentity has been authenticated by having a process identifier thatmatches the process identifier associated with the requested data. Ifthe requesting process or entity can provide evidence of authenticity(i.e., the matching process identifier), then the encryption anddecryption module may decrypt the requested data and provide thedecrypted data to the requesting process or entity. However, if therequesting process or entity cannot provide evidence of authenticity,then the externally readable data structure would have its datanullified and the encryption and decryption module would simply disallowtransfer from the chip-internal storage element to the externallyreadable location.

In one option, all external chip data accesses may utilize achallenge-response using an encrypted exchange of information tovalidate the authenticity of the requesting element. In the case of ashared library, this challenge-response mechanism may be used to ensurethat the instance of the library acting on behalf of a given process isonly able to see data for that process. For example, the CPU package maysupport process identifier inheritance (or process tag bit inheritance)by the shared library or other linked process, such that the sharedlibrary may only assume the identity of the process that is using theshared library in a given thread of execution. When code from the sharedlibrary is loaded, the OS kernel may dynamically tag or associate theprocess identifier of the executing process with the shared librarycode. For example, this tagging of a dynamic instruction stream mayoccur in a fetch unit of the processor, after the instruction is pulledfrom the instruction cache.

Process and thread identity is preferably assigned by the operatingsystem (OS) and may be conveyed to the CPU package by the OS kernel. Forexample, process identity may take the form of a tag that is uniqueamong active processes, such as a series of tag bits. In one option, aprocess is assigned a tag that is used to keep processes from havingaccess to each other's memory, and this same tag could be used furtheras an index into the key store for protecting processor state data frombeing accessed by other processes. However, since some processes mayhave privileged access to all memory, reusing such a tag might allowthose processes to gain access to the encrypted data of other processes.In a further option, the OS kernel may assign a separate tag to eachprocess for the purpose of protecting processor state data from beingaccessed by other processes.

A process may grant trust to another process or entity using any knownmethod of granting trust. For example, a granting process may give a“secret” to a second process that proves trust was established. Thesecond process (the grantee) may then present the secret (preferablyincluding elements of identifying information that could not be forged)to allow the second process to impersonate the granting process foraccess to processor state data. In one example, the “secret” may be apassword. Accordingly, the “secret” may be used to authenticate aprocess rather than the process identifier, although the “secret” may beused in the same manner described for the process identifier.

In order to validate authenticity of a requesting entity, a“challenge-response” process may be used between the requesting entity(i.e., the process that is requesting data) and owning entity (i.e., theprocess that owns the data). For example, a secret (such as a password)may be used the owner process (or arbiter process, such as the OSkernel) to securely transmit a challenge to the requesting process,whereupon the requesting process must return a response with anencrypted value that is some predetermined function of the originallyoffered information, thus proving that it was able to decrypt thechallenge. For instance, in the computer network authentication protocolknown as Kerberos, the challenge is an encrypted integer N, while theresponse is the encrypted integer N+1, proving that the other end wasable to decrypt the integer N. In other variations, a hash functionoperates on a password and a random challenge value to create a responsevalue.

Optionally, the OS kernel may act as arbiter of such data accessrequests, possibly including use of a Trusted Platform Module (TPM)which can be used for secure storage of encryption keys. All of thestorage locations are matters of preferred embodiments, wherein the keystore within the CPU package never externalizes its encryption keys.

A single CPU package may include multiple processor cores that may sharea single encryption key store for that CPU package. However, in acompute node having multiple CPU packages, a process may run on bothpackages and has the same need for data protection. Optionally, theprocess may be separately registered with each CPU package, such thatthe process has a separate process identifier or tag and encryption keyon each CPU package. Therefore, the process is independently protectedon each CPU package. Accordingly, the process is authorized to accessits own data on each CPU package, but uses different encryption keys oneach CPU package in a manner that is transparent to the process.

Embodiments may include a memory controller with a security mechanismfor protecting data, where the security mechanism is analogous to thatdisclosed for the processor state data within the one or more processorcores. Accordingly, the memory controller may have its own encryptionand decryption module, and have access to a second key store storingtag-key pairs for use by the memory controller. Optionally, a processidentifier or tag that has been assigned to the process by the OS kernelmay be reused in the memory controller, although the process identifieror tag may be associated with a different encryption key. Optionally,the memory controller may have its own encryption staging buffer andlogic module, but utilize the same key store used by the one or moreprocessor cores.

Various embodiments or various aspects of one or more of the embodimentsmay take the form of a computer program product comprising computerreadable storage media that is not a transitory signal having programinstructions embodied therewith, wherein the program instructions areexecutable by a processor to perform a disclosed method. A separatedescription of the methods will not be duplicated in the context of acomputer program product.

FIG. 1 is a diagram of an apparatus 10 including a CPU package 12including a first processor core 20 forming an instruction path 22. TheCPU package 12 also includes a trusted key store 30 operatively coupledto, and accessible by, the first processor core 20. The instruction path22 of the processor core 20 is shown schematically to be running a HostOperating System “A” (23A) and a Guest Operating System “B” (23B), butany number of operating systems and other processes may be handled inaccordance with one of the disclosed embodiments.

The apparatus further includes a memory controller 40 that isoperatively coupled to the processor core 20 for receiving readinstructions and write instructions from the processor core 20. In theembodiment shown, the memory controller 40 includes memory control logic43, a cache controller 41, cache memory 42, and an encryption anddecryption module 44. The encryption and decryption module 44 mayencrypt and store data in memory, such as in the cache memory 42 or thememory modules 46, for either the host OS 32A or the Guest OS 23B. Dataowned by either operating system is encrypted and decrypted by thesecond encryption and decryption module 44 using the encryption keyassigned to that operating system. The encryption and decryption module44 is operatively coupled to the trusted key store 30 and may obtain theencryption key associated with which ever operating system is requestinga read or write action. As shown, the trusted key store 30 isillustrated as a data table including a plurality of records (rows),wherein each row includes a process identifier, tag bits and anencryption key. However, the key store may store the data in anysuitable format other than a table. In this example, the processidentifier identifies one of the operating systems, but in otherembodiments may be used to identify other processes or applications.

As shown in FIG. 1, Process A (23A) has been assigned a processidentifier in the form of a tag (Tag A) and Process B (23B) has beenassigned a process identifier in the form of a tag (Tag B). Accordingly,instructions traversing the instruction path 22 and data being stored inthe cache memory 42 or memory modules 46 is appended or accompanied bythe tag corresponding to the process that owns the instruction or data.In this manner, a process that owns encrypted data stored in the cachememory 42 or memory modules 46 will have permission for the encryptionand decryption module 26 to decrypt and provide that data to theprocess. Only a process that has a tag matching the tag associated withthe data in the registers will be able to obtain the data. Any type ornumber of memory devices may be managed in this manner.

FIG. 2 is a diagram of an apparatus 10 including a CPU package 12 with afirst processor core 20 forming an instruction path 22, data registers24 that may be externally accessible through a debug port, and anencryption and decryption module 26 disposed in a communication pathbetween the instruction path 22 and the data registers 24. The CPUpackage also includes a key store 30 operatively coupled to, andaccessible by, the encryption and decryption module 26. The encryptionand decryption module 26 may encrypt and store data in the dataregisters 24 for each of a plurality of processes being handled in theinstruction path. For example, the plurality of processes are shownschematically to include a Host OS “A” (23A) and a Guest OS “B” (23B),but any number of operating systems and processes may be handled inaccordance with various embodiments. Data owned by each operating systemis encrypted and decrypted by the encryption and decryption module 26using an encryption key assigned to the operating system. Furthermore,the key store 30 may store the encryption key assigned to each of theoperating systems and perhaps other processes, wherein the key store isinaccessible outside the CPU package 12. As shown, the key store 30 isillustrated as a data table including a plurality of records (rows),wherein each row includes a process identifier, tag bits and anencryption key. However, the key store may store the data in anysuitable format other than a table.

Optionally, the encryption and decryption module 26 may also assign anencryption key to each of the plurality of operating systems and otherprocesses being handled in the instruction path 22. The data registers24 or other data structures may store the encrypted data along with aprocess identifier or tag assigned to the process that owns the data.Still further, each process identifier may be assigned to a process bythe trusted key store, which may be a trusted platform module.

In a further embodiment, the CPU package 12 further comprises a memorycontroller 40 including memory control logic 43, a cache controller 41,cache memory 42, and an encryption and decryption module 44. Theencryption and decryption module 44 may encrypt and store data in thecache memory 42 and/or the memory modules 46 for each of the operatingsystems being handled in the instruction path 22, wherein data owned byeach operating system is encrypted and decrypted by the encryption anddecryption module 44 using the encryption key assigned to that operatingsystem. The encryption and decryption module 44 has access to the keystore 30 and may obtain the encryption key necessary to use on behalf ofthe operating system requesting a read or write from the cache memory 42or a memory module 46. The encryption and decryption module 44 mayencrypt and decrypt data to and from the cache memory 42 and the memorymodules 46 in the same or similar manner as the encryption anddecryption module 26 encrypts and decrypts data to and from theregisters 24.

Still further, the CPU package may further include other externallyaccessible data structures, such as the off-chip readable data storage50, and an encryption and decryption module controlling data into andout of each of the externally accessible data structures. While eachexternally accessible data structure may have its own encryption anddecryption module, the illustration shows the encryption and decryptionmodule 44 controlling data in and out of both the cache memory 42, thememory modules 46 and the off-chip readable data storage 50.

As shown in FIG. 2, Host OS “A” (23A) has been assigned a processidentifier in the form of a tag (Tag A) and Guest OS “B” (23B) has beenassigned a process identifier in the form of a tag (Tag B). Accordingly,instructions traversing the instruction path 22 and data being stored inthe data registers 24 are appended or accompanied by the tagcorresponding to the operating system that owns the instruction or data.In this manner, an operating system or other process that owns encrypteddata stored in the data registers 24 will have permission for theencryption and decryption module 26 to decrypt and provide that data tothe process. Only an operating system or other process that has a tagmatching the tag associated with the data in the registers/memory willbe able to obtain the data. Any number of data registers and memorystructures may be controlled in this manner.

Still further, an external entity 60, such as a debugger, is shown incommunication with the data storage structure 50. If the external entityattempts to reach a particular portion of the data in the data storagestructure 50 and if the external entity is authenticated by presentingthe tag associated with the requested data, then the encryption anddecryption module 44 will decrypt the requested data and provide thedata to the external entity 60. However, if the external entity 60 doesnot present a tag matching the tag associated with the requested data,then the encryption and decryption module 44 will not decrypt therequested data. In accordance with the embodiment of FIG. 2, the hostoperating system is unable to obtain data that is owned by the guestoperating system.

FIG. 3 is a flowchart of a method 70 according to one embodiment. Instep 72, the method executes a host operating system and a guestoperating system on a host central processing unit package. In step 74,the method stores a process identifier assigned to the guest operatingsystem in association with an encryption key received from (or assignedto) the guest operating system in a trusted key store, wherein theencryption key received from the guest operating system is notaccessible to the host operating system. Step 76 encrypts data owned bythe guest operating system using the encryption key received from (orassigned to) the guest operating system and storing the encrypted dataon a memory module in response to a write command from the guestoperating system, wherein the encrypted data is stored on the memorymodule in association with the process identifier assigned to the guestoperating system. Then, step 78 includes decrypting encrypted data ownedby the guest operating system using the encryption key received from (orassigned to) with the guest operating system and providing the decrypteddata to the guest operating system in response to a read command fromthe guest operating system.

FIG. 4 is a flowchart of a method 80 according to another embodiment.The method 80 may be considered an initialization process, which mayoccur prior to the steps of method 70. In step 82, the method includesproviding, by the host, a digital certificate including a public key forthe host to the guest. Step 84 includes receiving, by the host, a publickey for the guest from the guest. In step 86, the host assigns theprocess identifier to the guest. In step 88, the method establishes asecure channel between the host and the guest using the public key forthe host and the public key for the guest. Accordingly, the method may,in step 90, inform the guest of the process identifier assigned to theguest over the secure channel and, in step 92, receive, by the host, theencryption key from the guest over the secure channel for use inencrypting and decrypting data for the guest. Step 94 includesreceiving, by the host, the guest operating system in an encrypted form,and step 96 includes decrypting the guest operating system using theencryption key received from the guest.

As will be appreciated by one skilled in the art, embodiments may takethe form of a system, method or computer program product. Accordingly,embodiments may take the form of an entirely hardware embodiment, anentirely software embodiment (including firmware, resident software,micro-code, etc.) or an embodiment combining software and hardwareaspects that may all generally be referred to herein as a “circuit,”“module” or “system.” Furthermore, embodiments may take the form of acomputer program product embodied in one or more computer readablemedium(s) having computer readable program code embodied thereon.

Any combination of one or more computer readable storage medium(s) maybe utilized. A computer readable storage medium may be, for example, butnot limited to, an electronic, magnetic, optical, electromagnetic,infrared, or semiconductor system, apparatus, or device, or any suitablecombination of the foregoing. More specific examples (a non-exhaustivelist) of the computer readable storage medium would include thefollowing: a portable computer diskette, a hard disk, a random accessmemory (RAM), a read-only memory (ROM), an erasable programmableread-only memory (EPROM or Flash memory), a portable compact discread-only memory (CD-ROM), an optical storage device, a magnetic storagedevice, or any suitable combination of the foregoing. In the context ofthis document, a computer readable storage medium may be any tangiblemedium that can contain, or store a program for use by or in connectionwith an instruction execution system, apparatus, or device. Furthermore,any program instruction or code that is embodied on such computerreadable storage media (including forms referred to as volatile memory)that is not a transitory signal are, for the avoidance of doubt,considered “non-transitory”.

Program code embodied on a computer readable storage medium may betransmitted using any appropriate medium, including but not limited towireless, wireline, optical fiber cable, RF, etc., or any suitablecombination of the foregoing. Computer program code for carrying outvarious operations may be written in any combination of one or moreprogramming languages, including an object oriented programming languagesuch as Java, Smalltalk, C++ or the like and conventional proceduralprogramming languages, such as the “C” programming language or similarprogramming languages. The program code may execute entirely on theuser's computer, partly on the user's computer, as a stand-alonesoftware package, partly on the user's computer and partly on a remotecomputer or entirely on the remote computer or server. In the latterscenario, the remote computer may be connected to the user's computerthrough any type of network, including a local area network (LAN) or awide area network (WAN), or the connection may be made to an externalcomputer (for example, through the Internet using an Internet ServiceProvider).

Embodiments may be described with reference to flowchart illustrationsand/or block diagrams of methods, apparatus (systems) and computerprogram products. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer program instructions. These computer program instructions maybe provided to a processor of a general purpose computer, specialpurpose computer, and/or other programmable data processing apparatus toproduce a machine, such that the instructions, which execute via theprocessor of the computer or other programmable data processingapparatus, create means for implementing the functions/acts specified inthe flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored on computerreadable storage media that is not a transitory signal, such that theprogram instructions can direct a computer, other programmable dataprocessing apparatus, or other devices to function in a particularmanner, and such that the program instructions stored in the computerreadable storage medium produce an article of manufacture.

The computer program instructions may also be loaded onto a computer,other programmable data processing apparatus, or other devices to causea series of operational steps to be performed on the computer, otherprogrammable apparatus or other devices to produce a computerimplemented process such that the instructions which execute on thecomputer or other programmable apparatus provide processes forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods and computer program products. In this regard, eachblock in the flowchart or block diagrams may represent a module,segment, or portion of code, which comprises one or more executableinstructions for implementing the specified logical function(s). Itshould also be noted that, in some alternative implementations, thefunctions noted in the block may occur out of the order noted in thefigures. For example, two blocks shown in succession may, in fact, beexecuted substantially concurrently, or the blocks may sometimes beexecuted in the reverse order, depending upon the functionalityinvolved. It will also be noted that each block of the block diagramsand/or flowchart illustration, and combinations of blocks in the blockdiagrams and/or flowchart illustration, can be implemented by specialpurpose hardware-based systems that perform the specified functions oracts, or combinations of special purpose hardware and computerinstructions.

The terminology used herein is for the purpose of describing particularembodiments only and is not intended to limit the scope of the claims.As used herein, the singular forms “a”, “an” and “the” are intended toinclude the plural forms as well, unless the context clearly indicatesotherwise. It will be further understood that the terms “comprises”and/or “comprising,” when used in this specification, specify thepresence of stated features, integers, steps, operations, elements,components and/or groups, but do not preclude the presence or additionof one or more other features, integers, steps, operations, elements,components, and/or groups thereof. The terms “preferably,” “preferred,”“prefer,” “optionally,” “may,” and similar terms are used to indicatethat an item, condition or step being referred to is an optional (notrequired) feature of the embodiment.

The corresponding structures, materials, acts, and equivalents of allmeans or steps plus function elements in the claims below are intendedto include any structure, material, or act for performing the functionin combination with other claimed elements as specifically claimed.Embodiments have been presented for purposes of illustration anddescription, but it is not intended to be exhaustive or limited to theembodiments in the form disclosed. Many modifications and variationswill be apparent to those of ordinary skill in the art after readingthis disclosure. The disclosed embodiments were chosen and described asnon-limiting examples to enable others of ordinary skill in the art tounderstand these embodiments and other embodiments involvingmodifications suited to a particular implementation.

What is claimed is:
 1. An apparatus, comprising: one or more processorcore; a trusted key store operatively coupled to the one or moreprocessor cores; a memory controller operatively coupled to the one ormore processor cores and the trusted key store; and a memory moduleoperatively coupled to the memory controller; wherein the memorycontroller includes an encryption and decryption module that encryptsdata being stored to the memory module for a guest operating systembeing executed by the one or more processor cores and that decrypts databeing read from the memory module for the guest operating system,wherein data owned by the guest operating system is encrypted anddecrypted by the encryption and decryption module using an encryptionkey stored by the trusted key store in association with the guestoperating system.
 2. The apparatus of claim 1, wherein the trusted keystore is a trusted platform module.
 3. The apparatus of claim 2, whereinthe trusted platform module and the one or more processor cores arelocated on the same chip.
 4. The apparatus of claim 1, wherein theencryption key is assigned to the guest operating system by theencryption and decryption module.
 5. The apparatus of claim 1, whereinthe memory module stores the encrypted data along with a tag identifyingthe guest operating system.
 6. The apparatus of claim 1, furthercomprising: cache memory in the communication path between the memorycontroller and the memory module, wherein all data stored on the cachememory is encrypted using the encryption key associated with the guestoperating system that owns the data.
 7. The apparatus of claim 6,wherein the cache memory is a level three cache.
 8. The apparatus ofclaim 1, wherein the one or more processor cores include data registersand an encryption and decryption module that encrypts data being storedto the data registers for a guest operating system being executed by theone or more processor cores and that decrypts data being read from thedata registers for the guest operating system, wherein data stored onthe data registers that is owned by the guest operating system isencrypted and decrypted by the encryption and decryption module of theone or more processor cores using the encryption key stored by thetrusted key store in association with the guest operating system.
 9. Amethod, comprising: executing a host operating system and a guestoperating system on one or more processor cores; storing a processidentifier assigned to the guest operating system in association with anencryption key received from the guest operating system in a trusted keystore, wherein the encryption key received from the guest operatingsystem is not accessible to the host operating system; encrypting dataowned by the guest operating system using the encryption key receivedfrom the guest operating system and storing the encrypted data on amemory module in response to a write command from the guest operatingsystem, wherein the encrypted data is stored on the memory module inassociation with the process identifier assigned to the guest operatingsystem; and decrypting encrypted data owned by the guest operatingsystem using the encryption key received from the guest operating systemand providing the decrypted data to the guest operating system inresponse to a read command from the guest operating system.
 10. Themethod of claim 9, further comprising: verifying that the read commandis from the guest operating system.
 11. The method of claim 10, whereinverifying that the read command is from the guest operating system,includes determining that the read command includes a process identifierthat matches the process identifier stored on the memory module inassociation with the encrypted data.
 12. The method of claim 10, furthercomprising: preventing decryption of a requested portion of theencrypted data stored on the memory module in response to receiving aread request from a process having a process identifier that does notmatch the process identifier stored in the memory module along with therequested portion of the encrypted data.
 13. The method of claim 9,wherein the process identifier is a plurality of tag bits.
 14. Themethod of claim 13, further comprising: the one or more processor coresassociating the tag bits of a process with all instructions of the guestoperating system and all data owned by the guest operating system. 15.The method of claim 9, wherein data owned by the guest operating systemincludes data owned by any application being run on the guest operatingsystem.
 16. The method of claim 9, further comprising; encrypting dataowned by the guest operating system using the encryption key receivedfrom the guest operating system and storing the encrypted data on a dataregister of the one or more processor cores, wherein the encrypted datais stored on the data register in association with the processidentifier of the guest operating system; and decrypting encrypted datastored on the data register and owned by the guest operating systemusing the encryption key received from the guest operating system andproviding the decrypted data to the guest operating system.
 17. Themethod of claim 9, further comprising; providing, by the host, a digitalcertificate including a public key for the host to the guest; andreceiving, by the host, a public key for the guest from the guest. 18.The method of claim 17, further comprising: assigning, by the host, theprocess identifier to the guest; establishing a secure channel betweenthe host and the guest using the public key for the host and the publickey for the guest; informing the guest of the process identifierassigned to the guest over the secure channel; and receiving, by thehost, the encryption key from the guest over the secure channel for usein encrypting and decrypting data for the guest.
 19. The method of claim18, further comprising: receiving, by the host, the guest operatingsystem in an encrypted form; and decrypting the guest operating systemusing the encryption key received from the guest.
 20. A computer programproduct comprising computer readable storage media that is not atransitory signal having program instructions embodied therewith, theprogram instructions executable by a processor to: execute a hostoperating system and a guest operating system on one or more processorcore; store a process identifier assigned to the guest operating systemin association with an encryption key received from the guest operatingsystem in a trusted key store, wherein the encryption key received fromthe guest operating system is not accessible to the host operatingsystem; encrypt data owned by the guest operating system using theencryption key received from the guest operating system and store theencrypted data on a memory module in response to a write command fromthe guest operating system, wherein the encrypted data is stored on thememory module in association with the process identifier of the guestoperating system; and decrypt encrypted data owned by the guestoperating system using the encryption key received from the guestoperating system and provide the decrypted data to the guest operatingsystem in response to a read command from the guest operating system.